PHP rips Safe Unlink Technique and Memory Canaries

Friday, December 15. 2006

I was quite amused today when I saw a commit to the Zend Engine by Dmitry Stogov. With this commit PHP now has a safe unlink protection, a technique originally created by me for the glibc heap implementation in 2003, that was also ripped by Microsoft for XP-SP2. Basically the whole commit is a rip-off of a memory manager protection similiar to the one in Suhosin. A protection that was always considered a no-no for vanilla PHP while I was among the PHP Security Response Team.

Yeah, well you do not need to be Harry Potter to guess what Zend is trying to do with this commit and why it is commited now. Fact is, that the people behind this patch have obviously not a security background and therefore it is not a suprise that the implementation violates several DONOTS that exist for heap protections. It is less secure than the one in Suhosin and therefore it is quite likely that I will have to completely remove the code from this commit in future versions of our patch.

Actually one question remains. How does a safe_unlink and canary protection fit into the "PHP is secure" propaganda?

Posted by Stefan Esser in Security, PHP at 20:00

Comments (13)

Link to this post

Comments

Display comments as (Linear | Threaded)

#1 Cristian Rodriguez ()

I do not understand why they didin't use your patch that is better tested and already available in several BSD and linux distributions and being used in real life..

posted on Friday, December 15. 2006

#1.1 Stefan Esser wrote (Link) ()

Cristian,

just wait for the next Zend press announcements, then you will know.

posted on Friday, December 15. 2006

#1.2 Stanislav Malyshev ()

Probably because the author of "better tested" patch, unfortunately, does not seem to be willing to cooperate with other PHP developers - and goes so far as publicly announce his unwillingness. You can see an illustration to this in this exactly posting - in true free software spirit, he calls new PHP features "rip-offs" and while talking about how bad it is never mentions what exactly is bad and how it can be fixed, though making it appear as if he knows it. Obviously, this post is an example of an ego-trip rather than attempt to contribute something. This can give you a hint why cooperation with the author of the "better tested patch" is problematic.

posted on Saturday, December 16. 2006

#1.2.1 Stefan Esser wrote (Link) ()

Stanislav,

maybe I should enlight you that Cristian knows how I cooperate with others. He knows how unproblematic this is. I guess the main reason is that unlike many PHP developers he behaves like a grown up and knows how to deal with others on a professional level, he does not attack others for no reason.

And unlike PHP people he does not consider security researchers as useless troublemakers. A title I heard several times from your friends.

posted on Saturday, December 16. 2006

#1.2.1.1 Stanislav Malyshev ()

I am sure most of PHP group never considered security researches - and you in particular - as useless troublemakers. On the contrary, many people (including myself) value your contribution to PHP security and overall your security work. That said, if we take this blog post as an example, from security standpoint it is indeed next to useless - you do not point to what exactly is the problem, you do not explain why, you do not propose the solution, and you certainly do not go and discuss it where this discussion is due. Instead, you say "PHP group sucks, they stole my ideas and they do it wrong, so come to me and use my private PHP version instead". Would you consider such feedback useful?

posted on Thursday, December 21. 2006

#1.2.1.1.1 Stefan Esser wrote (Link) ()

Tell me one reason why I should help you?

I leave the PHP Security Response Team and this created more fuzz than expected. And what does Zend do? In every interview Zeev is claiming, that my reasons are a personal vendetta and that I do not believe that PHP is insecure.

Sorry. Your marketing propaganda sucks and you even started to believe it yourself. BTW: I am not developing my own PHP, I am developing a patch that adds security features.

This blog posting gives enough information. I tell people about the fact that PHP suddenly gets security features that were unthinkable while I was part of security@php.net. Now suddenly they get commited for only one reason: Marketing/Damage Control. And yes I consider them a lame rip-off.

The same damage control/marketing arguments work for the security patches that went into the PHP CVS during the last days. Fixing security bugs that were originally reported by me 10 months ago.

In less than 4 weeks, when the media stopped reporting about me leaving the team, the bug handling speed will be back to normal, which means 6 or more month per security bug...

posted on Thursday, December 21. 2006

#1.2.1.1.1.1 Stanislav Malyshev ()

Stefan, there's absolutely no reason you should help anybody. But if you are not, and people say you you are not helping, do not play innocence accused. You do not want to help - that's your right. You want to make acidic comments about how bad PHP security is and not contribute to fixing it - entirely your right. But exercising that right means also people would notice you did so and would say you did so.

Speaking of security features in PHP - making PHP more secure is ongoing process, in which you could be a lot of help, if you only stopped talking in terms of "oh you are so lame, I told you that ages ago, but now I'm not going to give even one detail because it's beneath me" and would get down to actual things that need to be fixed (yes, I know you do that in other cases, but in this case you obviously do not). If you choose not to - well, people would do that without you. If you don't like the speed or way it is done - well, you could change that. Participate, contribute, discuss, influence. Or don't - then it would be done without you.

posted on Friday, December 22. 2006

#1.2.1.1.1.1.1 Stefan Esser wrote (Link) ()

Ohh Stas,

i totally forgot that 2006 was the year were every PHP core developer turned into a security professional.

If you believe you can do the work without me: fine. Do it and stop writing comments in my blog.

I already explained that I left the PHP Security Response Team because any attempt to work with them is futile. They do not listen and believe to know everything better.

I will no longer take the blame for things that would be a lot different under my control and especially not when I get tons of insults day by day.

Ohh yeah and it is simply unacceptable for me that the PHP License is enforced on me but close friends of Zend can violate the PHP License as they want. Beside the fact that this special treatment is a violation of the Open Source idea.

posted on Saturday, December 23. 2006

#2 Andi Gutmans ()

Hi Stefan,

Please feel free to email me with the DONOTS which you think we should fix. I'd be be more than happy to hear the feedback and make improvements if necessary. We did indeed base our implementation on XP SP2. We deliberately avoided heap underflow protection as we believe it's a much less common case and the performance impact is too high. We do support it in debug mode, so we could have a switch that enables people to turn it on if they want, but again, I'm not sure that is neecessary. Another thing we still need to implement is actually starting the heap at a random address in order to stop it from being predictable on certain platforms. This is still in the works. Any suggestions for how to best accomplish that in a platform-independent way would also be very helpful.

Thanks,

Andi

posted on Friday, December 15. 2006

#2.1 Cristian Rodriguez ()

Please feel free to email me with the DONOTS which you think we should fix.

Better will be if he publish that information here, in his blog, in a public way.. so we all learn about it, we educate ourselfs about this topic. why to keep it in secret ? what's the point ? or PHP interpreter 's own security is a taboo ??

We deliberately avoided heap underflow protection as we believe it's a much less common case and the performance impact is too high. We do support it in debug mode, so we could have a switch that enables >people to turn it on if they want, but again, I'm not sure that is >neecessary.

yes a configure switch ,that let us, the users to decide what we want to use or not. most users probably won't care about few miliseconds more..

posted on Friday, December 15. 2006

#3 ilja ()

Hey stefan,
Are you implying you invented the concept of a safe unlink() with this post ?

posted on Saturday, December 16. 2006

#3.1 Stefan Esser wrote (Link) ()

Yes I am implying this.

I demonstrated this idea in 2003 in a bugtraq posting and after that it was taken into Openwall Linux. During 2004 safe_unlink and several other checks were merged into glibc's malloc() and also went into Microsoft XP SP2. Safe_unlinking is also part of Hardened-PHP/Suhosin since 2004. And now the idea is uses in Zend's memory manager.

So I have no clue If anyone "invented it" before me. But it is documented fact that I was the first talking about it in public.

posted on Saturday, December 16. 2006

#4 overdose ()

"Another thing we still need to implement is actually starting the heap at a random address in order to stop it from being predictable on certain platforms"

i don't think this is the stuff of a third party app but of the OS

posted on Friday, January 5. 2007

Add Comment

Name:

Email:

Homepage:

In reply to:

Comment:
Standard emoticons like :-) and ;-) are converted to images.

Remember Information? Subscribe to this entry
Submitted comments will be subject to moderation before being displayed.

Calendar